Telegram Group & Telegram Channel
🧠 Задача для .NET разработчиков: «Загадочная утечка памяти в ASP.NET Core приложении»

🧩 Уровень: Senior .NET / Backend Engineer
🎯 Цель: Найти и устранить причину роста памяти без падений и исключений

📍 Ситуация:

У вас — высоконагруженное API на ASP.NET Core (.NET 8), работающее под Linux в контейнере.
Сервис обрабатывает тысячи запросов в минуту. Мониторинг показывает:

- Память растёт стабильно, но не освобождается
- GC работает, но не очищает выделенную память
- dotnet-counters показывает рост в LOH (Large Object Heap)
- Приложение не падает, но хост начинает свапать и тормозить
- При перезапуске — память очищается, но через 2–3 часа снова заполняется

В логах — тишина, ошибок нет. Библиотеки: Newtonsoft.Json, HttpClient, MemoryCache, EF Core.

---

🧩 Твоя задача:

1. Почему .NET GC может не освобождать LOH, даже при работе GC?
2. Какие действия вызывают накопление в LOH?
3. Как можно отследить, какие объекты скапливаются в памяти?
4. Чем опасен повторный вызов HttpClient или StringBuilder без очистки?
5. Как корректно использовать MemoryCache, чтобы избежать утечек?


💡 Подсказка:

- LOH начинается с объектов > 85,000 байт
- Часто виноваты: большие строки, сериализация, `ToString()`,
🧠 Задача для .N🧠 Задача🧠 Задача
-
Задача для .NETможет хранить сильные ссылки бесконечно, если не задано время жизни
- Частое создание

🧩 Уровень: S— может удерживать сокеты в TIME_WAIT и загонять GC в ступор


🛠 Решение:

1. Запускаем профилировщик:

dotnet-gcdump collect -p <PID>
dotnet-gcdump analyze dump.gcdump


2. Смотрим типы с самым большим retained size: List<string>, byte[], MemoryStream
→ В коде — сериализация в JSON огромных объектов без ограничения глубины

3. Находим участок с JsonConvert.SerializeObject(hugeObject) без MaxDepth

4. Исправления:
- Добавить настройки сериализации:

new JsonSerializerSettings { MaxDepth = 5, ReferenceLoopHandling = Ignore }

- Ограничить MemoryCache по размеру:

new MemoryCache(new MemoryCacheOptions { SizeLimit = 100_000_000 });

- Использовать HttpClientFactory вместо new HttpClient() на каждый запрос

5. Альтернатива: перейти на System.Text.Json с Utf8JsonWriter — меньше аллокаций

📌 Вывод:
Даже без явных ошибок .NET-приложение может стабильно "утекать" в LOH — через сериализацию, кэш или неправильную работу с потоками. Только анализ дампа памяти и правильная конфигурация GC и кешей помогут найти такие проблемы.

@csharp_1001_notes



tg-me.com/csharp_1001_notes/694
Create:
Last Update:

🧠 Задача для .NET разработчиков: «Загадочная утечка памяти в ASP.NET Core приложении»

🧩 Уровень: Senior .NET / Backend Engineer
🎯 Цель: Найти и устранить причину роста памяти без падений и исключений

📍 Ситуация:

У вас — высоконагруженное API на ASP.NET Core (.NET 8), работающее под Linux в контейнере.
Сервис обрабатывает тысячи запросов в минуту. Мониторинг показывает:

- Память растёт стабильно, но не освобождается
- GC работает, но не очищает выделенную память
- dotnet-counters показывает рост в LOH (Large Object Heap)
- Приложение не падает, но хост начинает свапать и тормозить
- При перезапуске — память очищается, но через 2–3 часа снова заполняется

В логах — тишина, ошибок нет. Библиотеки: Newtonsoft.Json, HttpClient, MemoryCache, EF Core.

---

🧩 Твоя задача:

1. Почему .NET GC может не освобождать LOH, даже при работе GC?
2. Какие действия вызывают накопление в LOH?
3. Как можно отследить, какие объекты скапливаются в памяти?
4. Чем опасен повторный вызов HttpClient или StringBuilder без очистки?
5. Как корректно использовать MemoryCache, чтобы избежать утечек?


💡 Подсказка:

- LOH начинается с объектов > 85,000 байт
- Часто виноваты: большие строки, сериализация, `ToString()`,
🧠 Задача для .N🧠 Задача🧠 Задача
-
Задача для .NETможет хранить сильные ссылки бесконечно, если не задано время жизни
- Частое создание

🧩 Уровень: S— может удерживать сокеты в TIME_WAIT и загонять GC в ступор


🛠 Решение:

1. Запускаем профилировщик:


dotnet-gcdump collect -p <PID>
dotnet-gcdump analyze dump.gcdump


2. Смотрим типы с самым большим retained size: List<string>, byte[], MemoryStream
→ В коде — сериализация в JSON огромных объектов без ограничения глубины

3. Находим участок с JsonConvert.SerializeObject(hugeObject) без MaxDepth

4. Исправления:
- Добавить настройки сериализации:

new JsonSerializerSettings { MaxDepth = 5, ReferenceLoopHandling = Ignore }

- Ограничить MemoryCache по размеру:

new MemoryCache(new MemoryCacheOptions { SizeLimit = 100_000_000 });

- Использовать HttpClientFactory вместо new HttpClient() на каждый запрос

5. Альтернатива: перейти на System.Text.Json с Utf8JsonWriter — меньше аллокаций

📌 Вывод:
Даже без явных ошибок .NET-приложение может стабильно "утекать" в LOH — через сериализацию, кэш или неправильную работу с потоками. Только анализ дампа памяти и правильная конфигурация GC и кешей помогут найти такие проблемы.

@csharp_1001_notes

BY C# 1001 notes


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/csharp_1001_notes/694

View MORE
Open in Telegram


C 1001 notes Telegram | DID YOU KNOW?

Date: |

Why Telegram?

Telegram has no known backdoors and, even though it is come in for criticism for using proprietary encryption methods instead of open-source ones, those have yet to be compromised. While no messaging app can guarantee a 100% impermeable defense against determined attackers, Telegram is vulnerabilities are few and either theoretical or based on spoof files fooling users into actively enabling an attack.

Unlimited members in Telegram group now

Telegram has made it easier for its users to communicate, as it has introduced a feature that allows more than 200,000 users in a group chat. However, if the users in a group chat move past 200,000, it changes into "Broadcast Group", but the feature comes with a restriction. Groups with close to 200k members can be converted to a Broadcast Group that allows unlimited members. Only admins can post in Broadcast Groups, but everyone can read along and participate in group Voice Chats," Telegram added.

C 1001 notes from pl


Telegram C# 1001 notes
FROM USA